Subject: ASM Split

From: [email-masked] (John Palombo)
Date: Fri, 9 Sep 1994 10:42:45 +0000

I have finally reached the line in my "to do" list which is
"document the ASM split for the Validation BOF"!  Attached below
is an edited extract from our SNAP APPN Architecture Guide, which
documents our rationale for splitting ASM into two components, and
provides some detail on how we have implemented the split.

Hopefully this will not only engender some discussion on
ASM, but will also provide some impetus to the other promised
notes on other interesting splits (particularly CS and SS)!

Cheers, John Palombo
Data Connection Ltd.

==================================================================

SPLITTING ASM
-------------

The SNAP APPN implementation splits ASM, as architected in the
SNA APPN Architecture Reference, into two distinct subcomponents.

-    The Address Space instance subcomponent (referred to as AS)
     is responsible for all functions associated with a
     particular TG or Path Control instance, namely

     -    managing the address space associated with the TG

     -    pacing BINDs travelling over the TG

     -    reassembling BINDs and RSP(BIND)s received over the TG

     -    routing session control messages once the initial LFSID
          assignment has been made.

     Each AS runs as a separate N-BASE process.

-    The Address Space Manager subcomponent (referred to as ASM)
     is responsible for "global" functions, including

     -    coordinating the creation and destruction of AS
          instances when links are initiated and terminated

     -    maintaining information about the whereabouts of NAUs
          defined at the local node (and using this information
          to carry out initial routing of incoming session
          initiation messages).

The figure below shows how the decomposition into ASM and AS affects signal
flows.  Note that other node components experience no change.

The rationale behind this decomposition is as follows.

-    It is possible (if not likely) that vendors will want to run
     Path Control on a separate board.  In that situation it is
     far more efficient if the code which manages the address
     space co-resides with the Path Control code.

-    In the SNA APPN Architecture Reference, Path Control
     maintains a separate address space table for routing data to
     Half Session instances.  Unfortunately, the use of parallel
     address space tables for ASM and PC leads to certain
     coordination problems, such as what should happen if Path
     Control fails to acquire memory for a new LFSID, after ASM
     has already assigned the LFSID and forwarded the BIND.

     A one-to-one correspondence between AS and PC instances -
     together with a shared address space table - closes these
     windows.

                            BUFFERS_AVAILABLE
                           +----------------------------------------------+
                           |                      +--+                    |
+----+ DEACTIVATE_ROUTE    |                    +-++ |                  +--+
|    |<--------------------|------------------- |  | |                  |  |
|    | ACTIVATE_AS         V   create           |  | |                  |  |
|    | ----------------->+---+ - - - - - - - - >|  | | BUFFERS_RESERVED |BM|
|    | ACTIVATE_AS_RSP   |   | destroy          |  | |<---------------- |  |
| CS |<----------------- |   | - - - - - - - - >|  | |                  +--+
|    | DEACTIVATE_AS     |   | FLUSH_LS         |  | |
|    | ----------------->|   | ---------------->|  | |
|    | AS_DEACTIVATED    |   | LS_FLUSHED       |  | |                  +--+
|    |<----------------- |   |<---------------- |  | | ALERT_SIGNAL     |  |
+----+                   |   |                  |  | | ---------------->|MS|
+----+                   |   |                  |  | | TRANSFER_MS_DATA |  |
|    | create            |   |                  |  | | ---------------->|  |
|    | - - - - - - - - ->|   |                  |  | |                  +--+
|    | UPDATE_NAU_NAME   |   |                  |  | |
|NOF |<----------------- |ASM| MU(UNBIND_RQ_SND)|  | |                    +--+
|    | DELETE_NAU_NAME   |   | ---------------->|  | |                  +-++ |
|    | ----------------->|   | MU(BIND_RSP_SEND)|  | |                  |  | |
|    | destroy           |   | ---------------->|  | |                  |  | |
+----+ ----------------->|   | MU(ACTPU_RSP_SND)|  | | MU(BIND_IPM_SEND)|  | |
  +--+                   |   | ---------------->|  | | ---------------->|  | |
+-++ | SESSION_ROUTE_INOP|   | MU(ACTLU_RSP_SND)|  | | MU(BIND_IPM_RCV) |  | |
|  | |<----------------- |   | ---------------->|  | |<---------------- |  | |
|  | | MU(BIND_RQ_RCV)   |   | MU(BIND_RQ_RCV)  |  | | MU(BIND_RQ_RCV)  |  | |
|  | |<----------------- |   |<---------------- |  | |<---------------- |  | |
|  | | MU(ACTPU_RQ_RCV)  |   | MU(ACTPU_RQ_RCV) |  | | MU(ACTPU_RQ_RCV) |  | |
|  | |<----------------- |   |<---------------- |  | |<---------------- |  | |
|  | | MU(ACTLU_RQ_RCV)  |   | MU(ACTLU_RQ_RCV) |  | | MU(ACTLU_RQ_RCV) |PC| |
|  | |<----------------- +---+<---------------- |AS| |<---------------- |  | |
|  | | MU( ... )                                |  | | MU( ... )        |  | |
|  | |<---------------------------------------->|  | | ---------------->|  | |
|  | | ASSIGN_LFSID                             |  | | AS_INITIALIZED   |  | |
|  | | ---------------------------------------->|  | | ---------------->|  | |
|SM| | ASSIGN_LFSID_RSP                         |  | | FREE_LFSID       |  | |
|  | |<---------------------------------------- |  | |<---------------- |  | |
|  | | FREE_LFSID                               |  | | FLUSH_LS         |  | |
|  | | ---------------------------------------->|  | | ---------------->|  | |
|  | | LFSID_IN_USE                             |  | | LS_FLUSHED       |  | |
|  | |<---------------------------------------- |  | |<---------------- |  | |
|  | | LFSID_IN_USE_RSP                         |  | | PC_HS_DISCONNECT |  +-+
|  | | ---------------------------------------->|  | | ---------------->+--+
|  +-+ PC_HS_DISCONNECT                         |  +-+
+--+   ---------------------------------------->+--+

      Figure :   Signal Flows with ASM/AS Decomposition.

The key elements of the design are as follows.

1.   On receipt of an ACTIVATE_AS from CS, ASM creates an AS
     instance associated with the newly-active TG.  ASM does not
     maintain any data structures containing information about AS
     instances of which it is the parent.  The Process ID of the
     new AS is returned to CS on the ACTIVATE_AS_RSP, and

     -    makes its way via SS to any SMs which need to activate
          sessions over the link
     -    is passed by CS on the DEACTIVATE_AS.

2.   A new signal, AS_INITIALIZED, is used to transfer to PC

     -    the location of the shared address space table

     -    address space control information (such as the number
          of SIDHs currently allocated)

     -    the Process ID of the newly-created AS instance.

     AS is responsible for acquiring the memory for the table.
     Access to the shared memory is controlled by

     -    the fact that PC and AS never use the same fields

     -    the flows defined by the protocol, which synchronize
          the assigning and freeing of LFSIDs

     -    N-BASE locks which control destruction of the address
          space.

3.   Local session activation and deactivation are handled
     identically to that described in the SNA APPN Architecture
     Reference, except that SM communicates directly with an AS
     instance using the Process ID passed back to CS at
     initialization.

4.   When a session initiation message (BIND or ACTPU or ACTLU)
     is received from PC as a result of a remote session
     activation, processing is split between the AS instance
     associated with that link, and ASM.

     -    After performing LFSID checks on the message (as well
          as pacing checks, reassembly, and length checks in the
          case of a BIND), AS logs the LFSID as "provisionally"
          in use (by inserting a uniquely recognizable Process ID
          - its own - in the field associated with the LFSID),
          and forwards the message to ASM.

     -    ASM tries to route the message to the appropriate
          component using information about NAUs supplied to it
          by the NOF.  (If ASM cannot route the message, or finds
          an error - such as a badly-formed Secondary LU Name -
          it sends a negative response back to AS, where the
          provisional assignment of the LFSID is revoked.)

     -    The destination component (usually SM) sends its
          session initiation response directly to the AS
          instance, where the provisional assignment of LFSID is
          either confirmed or deleted.

     -    If an UNBIND arrives at AS from PC after AS has
          forwarded a BIND to ASM, but has not yet received a
          RSP(BIND), AS queues the UNBIND, and will forward it to
          SM when the response arrives.

     -    If an incoming BIND arrives at AS, carrying the same
          LFSID as a BIND which AS has forwarded to ASM, but for
          which it has not yet received a RSP(BIND), then AS
          rejects the BIND with "LFSID in use" sense data.

5.   Local and remote session deactivation are processed by the
     AS instance.

6.   Deactivation of an address space is coordinated by ASM.

     -    ASM disables its queues from the NOF and CS, so that

                -    its NAU information cannot be changed
                -    it only has to cope with one deactivation at
                     a time.

     -    SESSION_ROUTE_INOP signals are sent to all NAUs known
          by ASM.  ASM requests posting from the Buffer Manager
          if it cannot get a buffer for a SESSION_ROUTE_INOP.
          ASM re-enables its queues from CS and the NOF as soon
          as all SESSION_ROUTE_INOPs have been sent.

     -    If the deactivation is orderly (as opposed to
          immediate), ASM sends a FLUSH_LS to AS, who routes it
          to the appropriate PC instance.  When PC has completed
          flushing its queues, it returns an LS_FLUSHED via AS to
          ASM, who sends an AS_DEACTIVATED to CS.

     -    If PC is not still using the address space (indicated
          by a flag in the shared address space control
          information), ASM releases the memory for the address
          space.  If PC is still accessing the address space, the
          memory is freed when PC is finally destroyed by CS.

     -    ASM destroys the AS instance.

-- 
==============================================================
John Palombo ([email-masked])
Data Connection Limited
Telephone:   +44 81 366 1177
Fax:         +44 81 367 8501
==============================================================